Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

To prevent later disaster, you must catch bugs as quickly as possible. It is worth spending extra time during the early phases of the project to make sure bugs do not contaminate the whole effort.

Stay in Control

One of the most sweeping things you can do to protect your productivity is to create an atmosphere of control. If you feel pressured to meet deadlines, the quality of your code suffers. You will not properly design routines before coding them and you will not spend enough time testing routines afterward. This introduces bugs into the code. Later, you will find the bugs and, in trying to fix them hastily, make more mistakes.

Figure 1.1  A traditional development pyramid.

Figure 1.2  Flaws in early stages of a project may spread throughout later stages.

Bugs breed bugs. One routine may compensate for the incorrect behavior of another. When the original bug is fixed, the compensating routine may break. With larger mistakes, you may write correct code based on faulty assumptions. When the assumptions are corrected, the code fails. Hastily repaired code becomes a fragile collection of dubious assumptions and exceptions instead of an elegant model of program behavior.

As you spend more time chasing and fixing these bugs that should never have occurred in the first place, morale sags. You soon become trapped in a vicious circle. You do not have time to do your job properly. You rush to finish new code and chase old bugs. Your haste creates more bugs that take even more of your dwindling time later. At this point, the bugs control you, not the other way around.

Breaking this cycle is not as difficult as you might think. All you need to do is avoid the bugs in the first place. That means performing adequate design before coding and adequate testing afterward. This reduces the number of bugs introduced during all stages of the project. You waste less time fixing avoidable bugs so you can spend more time on careful design, coding, and testing.

Pressure to meet deadlines and produce code more quickly can make you lose control again. Use these techniques to prevent backsliding:

Give design higher priority than deadlines. Plan carefully so you do not create bugs in the first place.

Give testing higher priority than deadlines. Take time to test your code as soon as it is written so you can catch bugs before they affect other programmers.

Use methodical care, not haste and carelessness. Do not make sloppy mistakes by working hastily.

Fix bugs as soon as you find them. Bugs only get harder to fix later.

Once you are in control, you can easily stay in control. You just need to force yourself to take the time needed to do your job properly. After some practice, good design and testing techniques become second nature, and staying in control is easy.

Intercept Unnecessary Work

If you manage other programmers, you can help them stay in control by intercepting unnecessary work. Do not make the team members waste their time on progress reports, executive summaries, and other administrative busy work. Take on as much of this as possible and leave the developers to their development tasks.

If you are not a manager, do not pass work on to other developers. If you are faced with a simple task that you can perform quickly and easily, do it. If you pass the job to someone else, you waste the time it takes you to tell them what to do and the time it takes them to understand what needs to be done.

Keep an eye on your time and make sure you are not doing unnecessary work. If you are losing a lot of time each day to tasks that do not help your project, try to eliminate some of your tasks. For example, in one project, I provided operating system and language support for the other project members. Occasionally, people outside the group would ask questions and I was happy to help. Over time, however, the outside demands grew. Eventually, I could barely keep up with my own tasks because I was spending so much time helping others. At that point I decided to answer outside questions only after 4:00 P.M. The outsiders stopped asking their simpler questions and I was able to regain control of my own work.

Sharing resources, even among different project teams, is a good thing. In this case, however, too much of a good thing could have jeopardized the project.

Set Priorities

Programming is full of tradeoffs. One of the most common tradeoffs is speed versus size. Many programs can be made faster by using more memory. For example, suppose you have a function that calculates the shortest distance between two points in a street network. You could make the program much faster if you precompute the shortest distance between every pair of points in the network and then store the results in a table. Now instead of using the function whenever you need a value, you can look the value up in the table. This makes the program faster, but takes a lot of memory. If the street network connects 10,000 points, the table will contain 100 million entries.

There are several other tradeoffs you make while writing code. For instance, you implicitly decide

•  How fast the code is

•  How much memory the code uses

•  How understandable the code is

•  How likely the code is to contain bugs

•  How much the code looks for errors

•  How hard the code is to test

•  How robust the code is

•  How soon the code will be finished

For instance, you might use a state-of-the-art algorithm taken from the latest research journals. That code will probably be very fast and may use very little memory. However, because it is state-of-the-art you cannot have had much prior experience with it. That means it is more likely to contain bugs than a simpler algorithm you may have been using for several years. Unless you are very careful and you have a thorough understanding of the literature, the code may be less understandable, too. Whether the code is robust and how well it performs error checking depends on your specific implementation.

You should discuss these tradeoffs with other project members so everyone has the same priorities. If one programmer places speed above all else and another places robustness first, they may be working against each other. Each may make unnecessary changes to code to try to meet these conflicting goals. Agree on the team’s priorities so everyone has the same objectives.

Change Priorities

Different stages in product development address different needs. The purpose of the initial development phase is to produce working code, and priorities should reflect that goal. You should place great emphasis on producing code that is understandable, maintainable, and less likely to contain bugs.

During the final stages of application development, you need to optimize the code. The goal is to improve the performance of those parts of the application that need it the most. Because the goals have changed, your priorities should change to match. At this point, it may be more important to produce fast code than code that is easy to read.